dgit.raspbian.org Git - gtk4.git/log

Make fast forward from 4.8.2+ds-3

[dgit --quilt=unapplied]

Disable clipboard test

This regularly times out on buildds, but I can't reproduce the hang
locally.

Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/4229
Forwarded: no

Gbp-Pq: Topic debian
Gbp-Pq: Name Disable-clipboard-test.patch

Disable inscription-markup.ui reftest

It's rendered 1px to the left of where it should be, which is not a
serious problem for practical use of GTK, but is a test failure.

Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/5099
Forwarded: not-needed, workaround

Gbp-Pq: Topic debian
Gbp-Pq: Name Disable-inscription-markup.ui-reftest.patch

reftests: Allow minor differences to be tolerated

Based on an earlier patch by Michael Biebl, as used in Debian's GTK 3
packaging, with additional inspiration from librsvg's reftests.

Each .ui or .node reftest can have an accompanying .keyfile file
like this:

    [reftest]
    tolerated-diff-level=20
    tolerated-diff-pixels=1000

If the image differs, but the number of pixels that differ is no more
than tolerated-diff-pixels and the differences are no more than
tolerated-diff-level, then we treat it as a success with warnings, save
the .diff.png for analysis, and use g_test_incomplete() to record the
test-case as "TODO".

Signed-off-by: Simon McVittie <smcv@debian.org>
Forwarded: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3195
Applied-upstream: no, upstream want reftests to be a strict pass/fail with identical results required

Gbp-Pq: Topic debian
Gbp-Pq: Name reftests-Allow-minor-differences-to-be-tolerated.patch

reftest_compare_surfaces: Report how much the images differ

In unattended/non-interactive/autobuilder environments where the images
are not trivially accessible, this provides a way to distinguish between
totally different rendering and more subtle issues.

Signed-off-by: Simon McVittie <smcv@debian.org>
Forwarded: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3195
Applied-upstream: no, upstream want reftests to be a strict pass/fail with identical results required

Gbp-Pq: Topic debian
Gbp-Pq: Name reftest_compare_surfaces-Report-how-much-the-images-diffe.patch

node-editor: Save test data relative to current working directory

This avoids hard-coding the GTK source directory into the binary, which
would make the binary non-reproducible across different source paths,
particularly in a distro build environment where the source directory
used by autobuilders will often not exist on end-user systems. The node
editor can still be used to create new test-cases by running it with the
GTK source directory as its current working directory.

Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/5403
Forwarded: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5297
Signed-off-by: Simon McVittie <smcv@debian.org>
Gbp-Pq: Name node-editor-Save-test-data-relative-to-current-working-di.patch

testsuite: Don't create .test files for flaky or failing tests

These tests can be run manually, but are not suitable for use as an
acceptance test, so let's not make frameworks like Debian's autopkgtest
run these when they run ginsttest-runner in the most obvious way.

Signed-off-by: Simon McVittie <smcv@debian.org>
Applied-upstream: 4.9.2, commit:94b57a967c492ab18df8142557710ba0b1a02cee

Gbp-Pq: Name testsuite-Don-t-create-.test-files-for-flaky-or-failing-t.patch

testsuite: Use separate setups for unstable tests instead of should_fail

There are two possible interpretations of "expected failure": either
the test *must* fail (exactly the inverse of an ordinary test, with
success becoming failure and failure becoming success), or the test
*may* fail (with success intended, but failure possible in some
environments). Autotools had the second interpretation, which seems
more useful in practice, but Meson has the first.

Instead of using should_fail, we can put the tests in one of two new
suites: "flaky" is intended for tests that succeed or fail unpredictably
according to the test environment or chance, while "failing" is for
tests that ought to succeed but currently never do as a result of a
bug or missing functionality. With a sufficiently new version of Meson,
the flaky and failing tests are not run by default, but can be requested
by running a setup that does not exclude them, with a command like:

meson test --setup=x11_unstable --suite=flaky --suite=failing

As a bonus, now that we're setting up setups and their excluded suites
programmatically, the gsk-compare-broadway tests are also excluded by
default when running the test setup for a non-broadway backend.

When running the tests in CI, --suite=gtk overrides the default
exclude_suites, so we have to specify --no-suite=flaky and
--no-suite=failing explicitly.

This arrangement is inspired by GNOME/glib!2987, which was contributed
by Marco Trevisan.

Signed-off-by: Simon McVittie <smcv@debian.org>
Applied-upstream: 4.9.2, commit:957dd49ef7d371926f90212bdf52b92742062e3e

Gbp-Pq: Name testsuite-Use-separate-setups-for-unstable-tests-instead-.patch

Update Basque translation

Origin: upstream, 4.8.3, commit:5186430d9d8b020c5546fdf11e5f051a05efe6f9

Gbp-Pq: Name Update-Basque-translation.patch

GLX: Add extra glXMakeContextCurrent () call to work around a DRI issue

Closes #4499, #5387, and #5170

See merge request GNOME/gtk!5285

(cherry picked from commit a9c9678e1f617755368f16424a03ae1f2d2ced4e)

Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/4499
Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/5170
Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/5387
Origin: upstream, 4.8.3, commit:b17ccd13e6ecc401bf9108d84ec089a62aae67c0

Gbp-Pq: Name GLX-Add-extra-glXMakeContextCurrent-call-to-work-around-a.patch

Update Abkhazian translation

Origin: upstream, 4.8.3, commit:b061d413e45ee5a0a243a87b05b07a9a8dfcef49

Gbp-Pq: Name Update-Abkhazian-translation-1.patch

gdksurface: Do not consider GDK_TOUCH_END/CANCEL as popup-dismiss worthy

GDK_TOUCH_END deserves the same treatment than GDK_BUTTON_RELEASE, since it's
subject to the same circumstances (popping up a menu on long press would be
immediately dismissed on release if we handled them there). Ideally, we would
want to match releases that we obtained a press for while grabbed, but as
the popup is also dismissed on GDK_BUTTON_PRESS/GDK_TOUCH_BEGIN, there's no
use for this tracking.

And GDK_TOUCH_CANCEL sounds weird as a reason to dismiss popups, just like
crossing events would.

(cherry-picked from commit 2ff4c77c5500110e2b387a8764ab19a92045ff4e)

Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2512
Origin: upstream, 4.8.3, commit:cc5ba83ebae31b20d8ac53fe1a32685b252a100d

Gbp-Pq: Name gdksurface-Do-not-consider-GDK_TOUCH_END-CANCEL-as-popup-.patch

gtktext: Claim gesture more selectively

Even though button 1 (or touch down) presses do most often have
an effect in one way or another (starting drag, moving focus,
starting selection, ...), there is one situation that they do
immediately nothing: When clicking on the entry does not move
the text caret around. Dragging might start a selection, but
the entry did not do anything just yet, and an immediate
button/touch release should remain at "did nothing".

And that is precisely the hint that the Wayland IM context's click
gesture takes, clicks that do not scroll nor move the caret around,
having the GtkText not claim the gesture in that situation makes
the IM gesture able to do its thing without in-fighting.

This is typically not a problem when the GtkText is embedded in
another GtkEditable implementation (e.g. GtkEntry), since the
IM gesture is inactive and capturing from the parent widget, so
gets a pass that it otherwise doesn't get when both gestures are
in the same widget. This makes it work regardless of GtkText not
being a child of a composite widget, like NautilusQueryEditor
and AdwRowEntry.

(cherry-picked from commit 09b982f0264e42bda3e8471bb25abec5ee742ecc)

Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/5351
Origin: upstream, 4.8.3, commit:3b940b12f64c78346cbea8a2fafde24690ecd9fe

Gbp-Pq: Name gtktext-Claim-gesture-more-selectively.patch

gdk/wayland: Use serial of the latest implicit grab available

When getting the serial for primary/clipboard selections we used a
function that largely relied on a GdkEvent being passed. We have
another available function that looks up the most recent serial
given the ongoing touch/tablet input as well.

This is the second best, compared to actually knowing the
input/device from the event that was received by the UI an triggered
the clipboard operation, and is already in use in other places
(e.g. window dragging). It is valid for these situations too.

Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/5250
Origin: upstream, 4.8.3, commit:873c304a9460ab30c4acf8e922605412cbededf8

Gbp-Pq: Name gdk-wayland-Use-serial-of-the-latest-implicit-grab-availa.patch

wayland: calculate union of geometry of all monitors for toplevel bounds

Signed-off-by: Colin Kinloch <colin.kinloch@collabora.com>
Origin: upstream, 4.8.3, commit:e551a9d1c4cbd66be04a1c45af172e7b5872f99c

Gbp-Pq: Name wayland-calculate-union-of-geometry-of-all-monitors-for-t.patch

focus: fall back to old behaviour if we didn't focus anything

8455b9ac74 seems to have introduced a problem where we can wind
up focusing no widget at all if the `while (parent)` loop doesn't
find a widget it can successfully move the focus to. This 'fixes'
that by falling back to doing the previous thing if we make it
all the way through that loop without moving the focus. Thanks to
@coreyberla for a hint to improve the implementation.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
Origin: upstream, 4.8.3, commit:824ff01eee3080672dd9c77005faca959f33a037

Gbp-Pq: Name focus-fall-back-to-old-behaviour-if-we-didn-t-focus-anyth.patch

gdk/wayland: Fix button mask calculation on button events

There's 2 things broken here:
- The mask was calculated on top of the GDK button (i.e. skipping
  4-7 buttons), so GDK_BUTTON4_MASK and GDK_BUTTON5_MASK were not
  assigned. This is now calculated on the (continuous) BTN_ evcodes
  so it is guaranteed that the next 2 physical buttons (i.e.
  back/forward) get these two places in the mask assigned.
- Furthermore, these buttons would be pushed to places in the
  modifier mask that they didn't belong to. It is now checked hard
  that only the first 5 buttons enable a modifier flag.

Overall, this ensures that no event masks with bonkers values are
forwarded, and that no stale implicit grabs are left after additional
buttons are pressed.

Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/5301
Origin: upstream, 4.8.3, commit:9b74027deaa4995ef582fdaf970ad881c3263cc1

Gbp-Pq: Name gdk-wayland-Fix-button-mask-calculation-on-button-events.patch

Update Hungarian translation

Origin: upstream, 4.8.3, commit:1e5b47c7ef5b3e444fb38c4072a6d4c84c584ef1

Gbp-Pq: Name Update-Hungarian-translation.patch

Updated Spanish translation

Origin: upstream, 4.8.3, commit:953c2ec3aed3b8ec4622e30d9cd3b6a56f7949db

Gbp-Pq: Name Updated-Spanish-translation.patch

Update Turkish translation

Origin: upstream, 4.8.3, commit:ff8aadba7bb693d8a49311907ef4b7ec79d52480

Gbp-Pq: Name Update-Turkish-translation.patch

Update Dutch translation

Origin: upstream, 4.8.3, commit:381c05607060c584779f9e6fab6f662ddfada1fa

Gbp-Pq: Name Update-Dutch-translation.patch

Update Georgian translation

Origin: upstream, 4.8.3, commit:f70c3548e10d229e136b2b189b55d20b2960dd44

Gbp-Pq: Name Update-Georgian-translation.patch

Update Abkhazian translation

Origin: upstream, 4.8.3, commit:5863ddbfdd8baa7f0febe69ac06d553561faed7b

Gbp-Pq: Name Update-Abkhazian-translation.patch

Revert "treepopover: Do not propagate natural width of content"

This reverts commit 9c919ffa462dd4511da0bfd19d36d2e15c51651b.

Origin: upstream, 4.8.3, commit:339b9eb1b979fffc751cc82d1142d6231be8f0c5
Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/5192

Gbp-Pq: Name Revert-treepopover-Do-not-propagate-natural-width-of-cont.patch

wayland: Fix keycode->keyval mapping

Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/5277
Origin: upstream, 4.8.3, commit:bb61b5fb5b9d9c6118a484bb2f5d83e5f97895cc
Forwarded: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5167

Gbp-Pq: Name wayland-Fix-keycode-keyval-mapping.patch

Release to unstable

Update changelog

Revert "Work around Mesa regresion #1025312 by forcing software rendering"

This reverts commit 21fbef6d66586999e9a57d1c57694a4b8771f1c7.

Update changelog

Update from upstream gtk-4-8 branch

- Fix visual artifacts on X11
- Update translations

d/patches: Sort Debian-specific patches to the end of the series

Add patch to make the node editor reproducible

Update changelog

Don't try to install man pages under nodoc build-profile

Drop unused docbook and xsltproc build-dependencies

The man pages now use python3-docutils instead.

Update changelog

Work around Mesa regresion #1025312 by forcing software rendering

We expect only software rendering to be available in typical buildd or
autopkgtest environments anyway, so this is no real loss.

d/rules: Remove redundant --libdir override

Add patches to improve handling of flaky/failing tests

Release to unstable

Make fast forward from 4.8.2+ds-2

[dgit --quilt=unapplied]

Disable inscription-markup.ui reftest

It's rendered 1px to the left of where it should be, which is not a
serious problem for practical use of GTK, but is a test failure.

Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/5099
Forwarded: not-needed, workaround

Gbp-Pq: Name Disable-inscription-markup.ui-reftest.patch

Disable clipboard test

This regularly times out on buildds, but I can't reproduce the hang
locally.

Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/4229
Forwarded: no

Gbp-Pq: Topic debian
Gbp-Pq: Name Disable-clipboard-test.patch

reftests: Allow minor differences to be tolerated

Based on an earlier patch by Michael Biebl, as used in Debian's GTK 3
packaging, with additional inspiration from librsvg's reftests.

Each .ui or .node reftest can have an accompanying .keyfile file
like this:

    [reftest]
    tolerated-diff-level=20
    tolerated-diff-pixels=1000

If the image differs, but the number of pixels that differ is no more
than tolerated-diff-pixels and the differences are no more than
tolerated-diff-level, then we treat it as a success with warnings, save
the .diff.png for analysis, and use g_test_incomplete() to record the
test-case as "TODO".

Signed-off-by: Simon McVittie <smcv@debian.org>
Forwarded: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3195
Applied-upstream: no, upstream want reftests to be a strict pass/fail with identical results required

Gbp-Pq: Name reftests-Allow-minor-differences-to-be-tolerated.patch

reftest_compare_surfaces: Report how much the images differ

In unattended/non-interactive/autobuilder environments where the images
are not trivially accessible, this provides a way to distinguish between
totally different rendering and more subtle issues.

Signed-off-by: Simon McVittie <smcv@debian.org>
Forwarded: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3195
Applied-upstream: no, upstream want reftests to be a strict pass/fail with identical results required

Gbp-Pq: Name reftest_compare_surfaces-Report-how-much-the-images-diffe.patch